The OPC UA application manifest contains the application registration information together with data related to PKI administration, such as paths to the certificate stores used.
The information contained in the OPC UA application manifest can roughly be divided into three areas:
One important piece of information is the subject name of the application instance certificate. The component uses the subject name to locate the instance certificate in the certificate store, and if it is not found, it attempts to create a new instance certificate, and store it with the subject name. The default subject name is created automatically, based on the description (title) of the application assembly, or (if the preceding yields a name that is too generic, such as ‘mscorlib’ in many hosted scenarios) from other sources of information, such as the executable’s FileVersionInfo, or a main module name.
The application URI can be specified explicitly, or (if left empty) the component will determine it automatically, using the ApplicationUriTemplateString Property. See OPC UA Application URI Derivation for the template syntax, and more details about how the application URI is determined.
If you want to use a specific subject name for your application instance certificate, set the EasyUAApplication.ApplicationParameters.ApplicationManifest.InstanceCertificateSubject Property accordingly.
If you leave the subject name empty, OPC Data Client will determine the subject name automatically from other information available. For example, when any of the properties below is not empty, OPC Data Client will include it in the subject name:
Other parameters that influence the application certificate creation are e.g. EasyUAApplication.ApplicationParameters.ApplicationManifest.ApplicationName, ApplicationUriString, and ProductUriString Property.
The full OPC UA application manifest contains a considerable amount of information. On one hand, all this information is critical to proper functioning of the OPC UA application itself, and it the OPC UA ecosystem. On the other hand, it would be cumbersome having to fill it in in its entirety for each new application. For this reason, OPC Data Client uses a process in which it automatically acquires the information needed in the OPC UA application manifest from various sources, and by combining the information in a prescribed way, it finally determines the effective application manifest, which is the OPC UA application manifest that will actually be used for OPC UA operations performed by OPC Data Client.
The effective application manifest is made first by composing the application manifest information from several sources, and then by resolving certain parts inside the manifest. The details of the composition and resolution processes are described further below.
The composition of the OPC UA application manifest is done using the following steps, in the specified order:
You can see that in the default state, only the first step (OPC UA automatic application manifest) provides the actual information; the remaining steps do nothing. If you want to modify some or all of the application provided by the automatic application manifest, you can use the OPC UA application manifest attribute to change it (this is the recommended way), or you can modify the information by writing code that changes it in the application parameters.
The reason why using the OPC UA application manifest attribute is preferred over setting the parameters from the code is that in many cases, application manifest information is needed outside of the application itself. For example, it might be needed for external administration tools. Such tools are able to read the OPC UA application manifest attribute from the application, but will not be able to see into the code and determine which values your application is setting to the application parameters.
The information in the OPC UA application manifest consists mostly of strings. Inthe composition process, a non-empty string in the application manifest that is being added to the composition overrides the existing information. An empty string leaves the information as it was. A string equal to "#" sets the information back to an empty string (this is rarely needed). For example, if the automatic application manifest determines the application name as "My Application", and you do not feel that this is the right name, you can set a non-empty application name in the OPC UA application manifest attribute, e.g. "Process Monitoring", and that will become the effective name.
After the composed application manifest is computed using the process described above, OPC Data Client resolves some information contained in it. Specifically, the special folder names that may be contained in certificate store paths (such as "LocalFolder") are resolved to absolute paths. The resolution process is important to assure that the certificate store paths do not change over time. Also, if/when the security configuration is exported from the application, it needs to be stripped off unnecessary context so that it is usable "as is", standalone.
The automatic application manifest attempts to provide reasonable information, either by using some common defaults, or by gathering the data about the application itself. Specifically:
Using the application manifest attribute is the preferred way to specify the OPC UA Application Manifest information, if it differs from what is provided by the automatic application manifest functionality. This method is only available in .NET applications.
The application manifest attribute is represented by the UAApplicationManifestAttribute Class. It contains properties for all information contained in the application manifest. As explained above in the "Application Manifest Composition" chapter, the application manifest attribute is evaluated after the automatic manifest attribute values are obtained. This means that you can only fill in the properties that you want to have changed from what is provided by the automatic application manifest functionality.
The application manifest attribute needs to be applied to the application assembly. The application assembly is usually the "main" assembly of you project. More precisely, it is:
Example syntax:
You can also manipulate the application manifets information directly from your code, in the application parameters object. As explained above, this method is not preferred, and should only be used if you cannot use the automatic application manifest, possibly in combination with the application manifest attribute.